fix: prevent orphaned crawl record when lock check fails in StartCrawler - #47

Problem

When two crawl requests arrive in rapid succession (or a scheduler fires
slightly early), StartCrawler could leave a zombie crawl row in the
database with end = NULL, permanently blocking all future crawls with
"project is already being crawled" — even after the real crawl finished.

Root cause

// Before this fix — SaveCrawl is called BEFORE the in-memory lock check
previousCrawl := s.repository.GetLastCrawl(&p)  // ← wasted DB query on rejection
crawl, err := s.repository.SaveCrawl(p)          // ← inserts row, end = NULL
...
c, err := s.addCrawler(u, &p, &b)                // ← lock already held → error
if err != nil {
    return err   // ← orphaned row never gets end set
}

SaveCrawl writes the DB record before addCrawler checks the
in-memory crawlers map. When addCrawler returns an error, the function
exits early and the goroutine that would call UpdateCrawl (which sets
end) is never started — leaving the row stuck forever.

Fix

Acquire the in-memory lock first, then do all DB writes. GetLastCrawl is
also moved after the lock check since its result is only used inside the
goroutine — no point querying the DB on a request that will be rejected.

c, err := s.addCrawler(u, &p, &b)        // lock first — fail fast, zero DB access
if err != nil {
    return err
}

previousCrawl := s.repository.GetLastCrawl(&p)   // only runs if lock was acquired

crawl, err := s.repository.SaveCrawl(p)           // only write if lock succeeded
if err != nil {
    s.removeCrawler(&p)                            // release lock if DB write fails
    return err
}

Changes

• internal/services/crawler.go — reorder addCrawler before GetLastCrawl
  and SaveCrawl; release the lock if SaveCrawl fails.
• internal/services/crawler_test.go — new test
  TestStartCrawlerNoDuplicateDBRecord asserts that a second concurrent
  StartCrawler call returns an error and does not invoke SaveCrawl.

Test plan

• go test ./internal/services/... passes including the new test.
• Trigger two rapid crawl requests for the same project; the second
  should be rejected and no new row with NULL end appears in crawls.
• Normal single crawl completes and the row gets its end timestamp set.
• If SaveCrawl fails (e.g. DB down), no orphaned in-memory lock entry
  remains and the project can be crawled once the DB recovers.

🤖 Generated with Claude Code